【イベントレポート】JAWS-UG meets Windows 〜 Windows開発者及びインフラエンジニアのためのDev&Ops On AWS 〜 #jawsug #jawsdays

吉江健斗

2017.03.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

3/11(土)にTOC五反田にて行われたJAWS-DAYSに参加してきました。
今回はWindowsに焦点を当てたDev&Opsとしてセッションを受講しました。

セッション概要

[DeepDive] JAWS-UG meets Windows ～Windows開発者およびインフラエンジニアのためのDev&Ops on AWS～

SlideShare

JAWS-UG Meets Windows (JAWS Days 2017)

JAWS-UG Meets Windows (JAWS Days 2017) from Amazon Web Services Japan

登壇者

アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト　渡邉源太様
アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト　福井厚様

セッションの概要について

Dev&Opsを主点として開発者、インフラ管理者視点の話をする

DevOpsとは？

ソフトウェア開発のライフサイクルは2つある。 - デリバリーパイプライン - フィードバックループ

これらのライフサイクルを高速に走らせることで「顧客の満足度」、「顧客のフィードバックをすぐに反映させる」ことを目的とする

AWSでは、DevOpsに取り組むにあたって様々なAWSプロダクトを提供している

DevOpsの話をすることの前提として「Infrastructure as code」という言葉がある
これは、「インフラを全てソフトウェア = インフラをソフトウェアにように扱う」
⇛これはオンプレではできなかったことがクラウドによって出来るようになったためより浸透していく

Infrastructure as Codeのメリット

サーバー台数が増えても構築に時間がかからない
コード=手順書になるのでコードを常にメンテナンスしておけば良い
手順を抜かしたり手順を間違う心配がない
同じコードを動かせば同じサーバーが出来上がる
コードの再利用が出来、拡張もしやすくなる
AWSでのInfrastructure as codeを実現するべく、多くのプログラミング言語にてSDKを多く提供している
このプログラミング言語の中で.NET coreも対応しているのでマルチプラットフォームで対応可能

Infrastructure as Code

Infrastructure as Codeを実現するにあたり、AWSの代表的なものとしてCloudFormationが挙げられる - JSON,YAMLに対応 - ドキュメントとして定義したものをデプロイ出来る

自動化のために使えるコマンドラインツールも多い。 - AWS CLI - AWS Tools for Windows Powershell

Windowsでは、OSより上位のレイヤーの作業をPowershellを使って実行を行うことが多いことからPowershellのコマンドレットを使用できる点でもオススメしている

Automation

AWSでも既存の運用を続けることが出来るオンプレにあるシステムをAWSに移行
↓
オンプレでやってる運用をAWSで使える(エクセル台帳を使って、管理を行う)
↓
これでは運用コストは減らない(サーバー台数が増えると管理面で大変になる)

この問題に対して、AWSではツールを代替することで運用コスト削減が可能になる - CloudWatchによるモニタリング - AWS Configによる変更管理

EC2 Systems Manager

EC2 Systems Managerを使うことで以下の恩恵を受けることが出来る - サーバーの運用コストを減らしてビジネス注力 - 品質安定 - オンプレミス、クラウド管理一元化 - セキュアなオペレーションを実現

EC2 Systems Managerではオンプレミス環境、EC2インスタンスで動作しているWindows,Linuxに対してシステム自動構成と継続的な管理出来る
EC2 Systems Managerを使用するにあたって、管理サーバーを立てる必要がない

Run Command

好きなコマンドをリモートで実行することが出来る
JSONベースのドキュメントでコマンド・タスクを定義して管理ができる
ポートも開ける必要がなく、セキュア運用が可能になる(パスワードを知らなくてもいい！)

「指定したインスタンスをドメインに参加させたい」を例とすると - 昔はRDPで入ってドメインに参加だった - AWSではドメイン参加用のコマンドを発行することでドメイン参加、コマンド実行等が可能になる

「Windows Nano ServerでIISのインストールしたい」を例とすると - Powershellのコマンドレットを入れることでインストールすることが出来る！

PatchManager

ベースラインを定義してWindowsパッチを定義できる
Patch Baselineを使ってカスタムパッチポリシーを定義
Maintenance Window内で実施できる
実施されたパッチングの結果はレポートされる

パッチ提供からどれぐらい待つ必要があるのかなどを指定できる

Container

Windowsはこれからだが、ユーザーは増えると予想している

そもそもコンテナとは何か

OS仮想化
プロセス隔離
イメージ
自動化

仮想マシンをプロセス単位でOSを使用する

コンテナを使用したDevOpsの観点で使われている
コンテナの中にあぷり、ミドルを含めることが出来る
Opsはコンテナ稼働環境のみ管理する

Windowsコンテナ

WindowsServer2016からコンテナが使えるようになる
このコンテナは大きく2つ種類がある。 - WindowsServerコンテナ - WindowsServerOS上で使える - Dockerをインストール - コンテナ実行 - Hyper-Vコンテナ - OS上でHyper-Vのハイパーバイザーを動作して、その上でコンテナプロセスを起動する - EC2上では実行することが出来ない

WindowsServer2016でコンテナを使う時の注意

通常のEC2で起動するWindowsServerAMIでは、EC2インスタンスとDockerプロセスでNWの競合が発生する。 DockerのExternalCIDRとWindowsServerのInternalCIDRがコンフリクトしてしまうそのため、Windowsコンテナを使用する時のホストに使用するAMIはMicrosoft Windows Server 2016 Base With ContainerのAMIを使いましょう！

コンテナを使う時にぶつかる壁

1台のサーバー上でDockerを扱うのは難しくない
複数台のクラスタ上でコンテナを管理するのは難しく、管理者の皆が頭に悩ませるところ
AWSユーザーへコンテナを使用する際の選択肢としては、ECSを使うとコンテナ管理がしやすくなる。
AWS基盤との統合も可能になる。
ダイナミックポートをマッピングしたりと柔軟にコンテナを配置してくれる
WindowsServerコンテナはBetaであるが、サポートしており、近々GAの予定
CloudFormation提供、ECSなどを提供する予定

注意点

LinuxとWindowsコンテナクラスタは混在できない
タスクのためにIAMロール追加が必要
WindowsServerはサイズが大きいので、DLでは時間がかかるのとストレージ容量が必要

開発者よりのDevOps

継続的デリバリと継続的デプロイメントの違いは？

継続的デリバリ
- テスト環境まででもいいからデプロイする
継続的デプロイメント
- 本番環境まででもいいからデプロイする

ソフトウェアのプロセスを自動化、バグの検出、アップデート配信これが実現出来るようになる = 開発者がより幸せになる

AWS Codeシリーズ

AWSのCodeシリーズによって、Testを除く各ソフトウェアリリースフェーズに対応することが出来る

Source

AWS CodeCommitによって、gitの機能を提供

Build

AWS CodeBuildによって、ビルドを提供

Test

Testは残念ながら存在していないたので、Third Partyにて対応

Production(Deploy)

AWS CodeDeployによって、各環境へのデプロイを提供

一連のソフトウェアリリースフェーズ全体をAWS Code Pipelineで自動管理することが出来、
Codeシリーズはwindowsでも使える！

AWS CodeCommitとは

セキュア、スケーラブルのマネージドgitソース管理
リポジトリとしてS3を使っている
耐久性が優れている
VisualStudioやEclipseからCodeCommitに繋げられるようになった

AWS CodeBuild

ビルド
一時的なコンテナを作ってユニットテスト等が出来る

CodeDeploy

あらゆるインスタンスへのデプロイを自動化に出来る
Blue/Greenデプロイメントも出来る
LifeCycle Hooksが使用できる
デプロイメントの方法も選択出来る
デプロイ作業量の調整が可能で「1つずつ」、「半分ずつ」、「全て一括」とデプロイ範囲を指定
デプロイ先のグループを指定することが可能

Codepipeline

各Code系を包括して扱える
ソフトウェアのプロセスをモデル化(見える化)が出来る様になる
Githubにpushしたタイミングでそれを検知してデプロイすることも出来る様になる

C# Lambda

これまではnode.jsなどが使用できていたが、C#がLambdaで使えるようになった - NET Coreベースで動作 - WIn32apiやCOMコンポーネントは呼べない - EC2で動いていることで呼び出せない - VisualStudioで統合された環境を利用できる - dotnet CLIベースの開発も可能になる

Lambda関数としてハンドラの名前は自由に指定することが出来る